(WIP) TS: fast forward and propagation policy change#10576
(WIP) TS: fast forward and propagation policy change#10576feiyang3cat wants to merge 11 commits into
Conversation
d5aa678 to
ad54d2d
Compare
861e03b to
b46afaa
Compare
9ae6e10 to
5d05103
Compare
1000c5e to
1753d5b
Compare
| disableChildPropagation := source.GetTimeSkippingInfo().GetConfig().GetDisableChildPropagation() | ||
| enabled := source.GetTimeSkippingInfo().GetConfig().GetEnabled() | ||
| if !enabled || disableChildPropagation { | ||
| return nil, nil |
There was a problem hiding this comment.
So we do not propagate the virtual time to the child in this case? This contradicts the described behavior in API PR:
// but a parent's fast_forward won't affect its child's execution. A flag is provided to disable propagation of the
// "enabled" flag to child workflows; regardless of that flag, a child workflow inherits the virtual time from the
// parent execution as its start time.```
| func (ms *MutableStateImpl) applyTimeSkippingBound(currentEventID int64) { | ||
| // applyFastForward (re)computes the FastForwardInfo using the new TimeSkippingConfig and propagated time-skippingstates. | ||
| // This method should be called whenever the TimeSkippingConfig is initialized or updated. | ||
| func (ms *MutableStateImpl) applyFastForward(currentEventID int64, propagatedTargetTime *timestamppb.Timestamp) { |
There was a problem hiding this comment.
Does this get executed even when unrelated field is updated? So say you have a 2h fast-forward set and you are 1 hour into it. If you update some other workflow option, it looks like you would just recalculate fast-forward to now + 2h.
| return tsc, stateProp | ||
| } | ||
|
|
||
| // propagateTimeSkippingToChild makes sure the start time of the child workflow execution |
There was a problem hiding this comment.
No changes needed, but just a comment for my understanding. Is my assumption about the behavior is correct: you fast forward 5 minutes, and all child workflows created during that time will skip the time unbounded.
There was a problem hiding this comment.
yes, but we recommend using fast forward with disable-propagation-for-child if child workflows also need to stop in the middle of somewhere and send signals
33747da to
55b6e00
Compare
55b6e00 to
31fd287
Compare
f349bb3 to
fe2c66e
Compare
0237a9e to
29fd7f1
Compare
29fd7f1 to
8e62251
Compare
What changed and why
make server compatible to breaking api change
time skipping fast forward api#786
change the propagation policy of time skipping to
virtual time is always propagated to have causal time
but the fast forward action is never propagated
configuration propagation is controlled by a separate flag
How did you test it?
Potential risks
the sequence of this pr